CFM-324_Attribute_Collector_Enroller_Plugin_store_cou_id_in_petition #399
Conversation
| // NOTE: Attribute Collector configuration can include multiple COU attributes/values, but the | ||
| // Petition record has only a single `cou_id` column. By convention/assumption we therefore | ||
| // select the first non-empty collected `cou_id` and ignore any additional values. |
There was a problem hiding this comment.
We should reconcile this. The current (draft) of the documentation asserts that we only collect a single Person Role in a given Enrollment Flow. This is consistent with the Petition having a single COU ID, and consistent with the current configuration of the Attribute Collector, in that, as far as I can tell, there is no way to group together collections of Person Role Attributes. In other words, if I collect two COUs and two Titles, which Title goes with which COU?
We can either (1) decide that Attribute Collector only collects one set of Person Role attributes (at least for the immediate future) or (2) decide to properly support multiple Person Roles. If we choose (1), then Attribute Collector should not allow multiple single valued attributes (COU, title, organization, sponsor, valid from, etc) to be configured. If we choose (2), then we need a way to associate attributes to Roles and we need to decide what it means for the Petition metadata.
There was a problem hiding this comment.
@benno Since an Enrollment Flow can have multiple steps—and we can instantiate the Attribute Collector in more than one step—we could use the Enrollment Flow Step as the grouping key for Person Role attributes. In other words, for each step where an Attribute Collector is present, we would allow one COU, one title, etc., and treat that set of attributes as a single Person Role. That would let a petition represent multiple roles (one per step) rather than forcing everything into a single COU/title set. The Petition could then expose a helper that returns an array of role-attribute groups (one per step), instead of assuming/forcing a single COU per petition.
There was a problem hiding this comment.
I think the use case of a subsequent Step being used to modify the values from a previous Step is likely, so I don't think the Enrollment Flow Step is a sufficient grouping ID. I don't think we can support this concept without additional administrator configuration.
Leveraging your suggestion, though, perhaps the simplest additional configuration would be an "Attribute Collector Role Number" set via the Attribute Collector configuration for each Step. If two Steps are configured with the same number (or if the numbers are left blank entirely) they refer to the same Role. This implies a single Step cannot collect attributes for multiple Roles, but that seems like a reasonable limitation.
I don't think this is a requirement for v5.2.0, so perhaps for v5.2.0 we limit the Attribute Collector to a single Person Role, and then add the additional capability in a later release.
Ioannis
force-pushed
the
CFM-324_Attribute_Collector_Enroller_Plugin_store_cou_id_in_petition
branch
from
04aab88 to
aec7633
Compare
Ioannis
force-pushed
the
CFM-324_Attribute_Collector_Enroller_Plugin_store_cou_id_in_petition
branch
3 times, most recently
from
618121b to
be4d8b6
Compare
Ioannis
force-pushed
the
CFM-324_Attribute_Collector_Enroller_Plugin_store_cou_id_in_petition
branch
2 times, most recently
from
37716af to
44a7fe9
Compare
|
|
Ioannis
force-pushed
the
CFM-324_Attribute_Collector_Enroller_Plugin_store_cou_id_in_petition
branch
from
1bc8768 to
375d221
Compare
2 participants
Configuration Level:
At the configuration level, the changes enforce data integrity by introducing an application business rule (ruleSingleValuedAttributeUnique) in EnrollmentAttributesTable. This rule prevents administrators from adding duplicate single-valued Person and Person Role attributes (such as cou_id, affiliation_type_id, title, department, organization, sponsor_person_id, manager_person_id, valid_from, and valid_through) within the same Attribute Collector plugin instance, rejecting conflicting duplicates with a localized error message.
Runtime Collection & Hydration Level:
During enrollment flow execution, the changes enable seamless cross-step attribute pre-population and preserve single Person Role consolidation. In AttributeCollectorsController and form rendering elements (field.php, fieldset-field.php), previously submitted petition values are matched by attribute name across steps, allowing subsequent Attribute Collector steps to display earlier values as editable defaults while updating Petition.cou_id deterministically for the active step. During finalization (hydrate), querying is scoped to the current step instance, and PersonRolesTable::saveAttributeCollectorPetitionAttributes() patches an existing non-pipeline PersonRole (or resolves it for role-level MVEAs) rather than creating new records on every step, guaranteeing that all Attribute Collector steps merge into exactly one unified Person Role for the enrollee.